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Abstract 

Agile software approaches have seen a steady rise over a decade and a half, but agile's place in the 
information systems (IS) undergraduate curriculum is far from settled. While agile concepts may 
arguably be taught in multiple places in the IS curriculum, this paper argues for its inclusion in a project 
management course. This paper builds on work by Schwalbe and the Project Management Institute 
(PMI) to define a set of topics for undergraduates. The co-authors, a professor and a senior student at 
a public, four-year university, consulted four sources: an industry partner, the PMI, the Schwalbe 
textbook, and published literature. The authors created course content, including a glossary of terms, 
individual and team assignments, and assessment items. Our thesis is that agile can be taught alongside 
traditional project management topics and broadly across PMBOK® areas. Results from the spring 
semester indicate that students demonstrated a sufficient level of mastery of outcomes. 
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1. INTRODUCTION 

The use of agile practices is becoming more and 
more prevalent. Since the publication of the Agile 
Manifesto (Beck et al., 2001), agile has gained in 
popularity. PMI's research has shown that the use 
of agile has tripled from December 2008 to May 
2011 (Schwalbe 2012) and has grown even more 
since 2011. According to the VersionOne (2014) 
State of Agile Survey, approximately 88% of 
respondents are practicing agile in the workplace. 

As agile gains ground in industry, it is important 
to consider its place in the IS curriculum. As it 
was formulated as a better way for developing 
software, it makes sense to include agile in 
courses that cover software development. The IS 
2010 model curriculum (Topi, et al., 2010) 
mentions "agile methods" in the topics list for the 


IS 2010.6 Systems Analysis & Design course. 
Programming and project management are two 
other courses that may incorporate agile 
methods, although the IS 2010 is silent in this 
regard. Schwalbe (Schwalbe, 2014, 2012) has 
incorporated agile into her project management 
textbook, however, and the Project Management 
Institute (PMI) has adopted agile concepts in its 
framework, offering an Agile Certified Practitioner 
(PMI-ACP®) certification (Project Management 
Institute, 2011). 

Motivated by the values that drove the originators 
of the Agile Manifesto, namely that agile methods 
are a better way, the authors set out to define 
course content and pedagogy to prepare students 
for an increasing agile world. The lead author is 
a professor teaching project manager to seniors 
in the information systems (IS), information 
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technology (IT), and health informatics (HI) 
majors at a midsize, southern, four-year, 
accredited, public university. The co-author was 
a senior IS major who had previously taken the 
course and was assisting the professor in a locally 
funded research project. In accordance with their 
responsibilities and common area of interest, the 
co-authors limited their focus to the project 
management course. The research question for 
the paper is, therefore, 

What is a best set of agile concepts and 
practices appropriate for an IS project 
management course? 

The expected contribution is to provide faculty 
members teaching PM courses with helpful 
guidance in putting together an effective agile 
component. 

2. APPROACH 

Several early decisions were made on the 
approach. The first was to not radically redesign 
the PM course, but to teach agile alongside 
traditional project management. The authors did 
not wish to risk being foolish by touting agile as a 
"silver bullet" (Brooks, 1987), and also 
recognized that not all situations are suitable for 
a completely agile approach. The approach 
enables comparison as well. The second decision 
was to teach agile throughout the course, and not 
just as a single topic, as agile provides for many 
different methods. Eventually, it was decided to 
use the well-accepted Project Management Body 
of Knowledge (PMBOK®) areas as a content 
framework for achieving coverage breadth. A 
third decision, as a result of the singular focus on 
the project management course, was to focus 
broadly on agile project management, rather than 
on agile software development, or developing a 
specific type of product. Our approach, in 
summary, is principally: 1-agile alongside, 2-agile 
throughout, and 3-project not product. 

We chose topics for each area and created 
content. Four sets of presentation slides were 
created and presented: 

• An introduction to agile 

• Is agile right for my project? 

• Agile in industry 

• Agile human resource management 

We also created a glossary, assignments and 
assessment items. A glossary of 40 vocabulary 
terms resulted, with at least one term falling into 
each of ten PMBOK areas. A ten-item multiple 
choice quiz was created and given to individuals 
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and teams as part of a team-based pedagogy 
(Michaelsen, Knight, and Fink, 2004) used in the 
class. A total of 25 multiple choice items were 
created overall, with others used on the midterm 
and final exams. Three individual assignments 
were given: 

• Financial evaluation methods problems 
(same as for traditional) 

• An online discussion forum on an Is agile 
right for my project? Case 

• A soft skills writing assignment on Am I 
ready for agile? 

The latter assignment requires students to take 
an emotional intelligence self-assessment "quiz" 
and write about their results. Student teams took 
part in an active learning assignment on planning 
poker, where individuals iteratively estimated 
task times using a Delphi-like technique. The 
final exam had an essay question on agile soft 
skills, and a burndown chart problem. These 
assignments and items were given in addition to 
the assignments, items, and activities already in 
place for traditional project management 
practices. 

3. AGILE ACROSS THE PMBOK AREAS 

For each of the ten PMBOK areas, we have defined 
one or more key topics for coverage in the project 
management course. In selecting these key 
topics, the key criteria were to identify something 
in every area and to select the more important 
topics within each area. We considered what 
already was covered in the Schwalbe text, as well 
as the emphasis of project over product. As for 
Schwalbe's coverage, she provides an extensive 
example case in an early chapter, done in both 
traditional and agile approaches. Many of the 
terms and concepts we used as agile were present 
in her text as well. See Table 1 that follows for a 
list of topics by PMBOK area. What was taught in 
the course was actually more than what is in the 
list, but the list in Table 1 represents a post hoc 
reflection on what is most important. 

Integration 

Project Integration Management is the area that 
incorporates and coordinates multiple areas at 
once. For Agile, it is the core values and 
principles that encapsulate all practices. Thus, 
the Agile Manifesto (Beck et al., 2001) is the 
critical coverage area. In the manifesto, which 
can be accessed at agilemanifesto.org, the 
signatories assert that a better way of developing 
software is to value the following: 
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Individuals and interactions over processes and 
tools 

Working software over comprehensive 
documentation 

Customer collaboration over contract negotiation 
Responding to change over following a plan 

Agile practices may change, but the practices 
should remain consistent with core values. 

We first introduce agile (Rajamanickam, 2005; 
Conforto and Amaral, 2010) with the discussion 
of the manifesto, and with a contrast between 
traditional and agile project management 
(Fernandez & Fernandez, 2008; Lipika & Sanjeev, 
2013), and, finally a discussion of conditions that 
are right for agile to be used (Augustine, Payne, 
Sencindiver & Woodcock, 2005; Nerur, 
Mahapatra & Mangalaraj, 2005). Agile is right for 
a project when: 

1. Project exhibits high variability in 

requirements 

2. Team members have a high knowledge base 
and can learn quickly 

3. Team members are willing to adapt to change 

4. Resources for project are easily accessible 

5. Customer is highly involved and in close 
proximity 

6. Value of the product to be delivered is very 
important to the customer 

7. Manager is comfortable with a facilitator role 

The planning game of extreme programming 
(Lindstrom and Jeffries, 2004), one of the popular 
agile approaches, calls for the customer-involved 
identification and prioritization of features, 
broken down into work tasks, then completed in 
a test-driven manner, iteratively throughout the 
project. This agile approach to planning is at the 
heart of agile project management and integrates 
the areas of scope, time, quality, and 
stakeholders, and more. 

Scope 

Project Scope Management covers all of the work 
needed to complete the project. Agile scope 
management revolves around the iterative 
identification of requirements, or features, called 
user stories, expressed in the terms the user can 
understand. The collection of prioritized stories 
and the work into which the stories are broken is 
called the backlog. The management of agile 
scope is iterative and customer-involved, and 
addressed by project integration management 
processes described above. In contrast to 
traditional project management, in which scope is 
fairly rigid, scope is highly variable in agile 
projects. Agile practitioners prefer responding to 
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change over following a plan. Scope change is a 
part of every project iteration, called sprints in 
Scrum (Shojaee, 2012), one of the two most 
popular agile approaches. 

Time 

It is difficult to define a singularly important agile 
concept in the area of Project Time Management. 
Perhaps it is the concept of timeboxing. Project 
schedules in agile are timeboxed, or fixed, into 
typically two to four week intervals called sprints. 
Rather than estimating how long work is going to 
take and trying to meet that estimate on a task- 
by-task basis, an agile project team breaks down 
and estimates stories using a technique such as 
planning poker, a Delphi like method. The team 
then picks the number of stories that can be 
completed in a sprint. The idea is to complete a 
cycle of activities in a sprint, including testing and 
user acceptance, allowing for variations in scope 
rather than time. A burndown chart is used to 
show progress and estimate project or sprint 
completion. With the Kanban approach, estimates 
are not even made. Instead, tasks are written on 
sticky notes and placed on a white board in one 
of three columns: to do, doing, and done, with 
notes moved from left to right as tasks change 
state. 


PMBOK area 

Key Agile Topics 

Integration 

Agile manifesto values & 
planning qame 

Scope 

User stories/backloq 

Time 

Timeboxing, sprints, 
planning poker, burndown 
chart, Kanban board 

Cost 

Financial evaluation methods 
(NPV, ROI) 

Quality 

Acceptance testing, 
definition of done, escaped 
defects 

Human 

Resources 

Emotional intelligence, 

Scrum Team 

Communication 

Co-location, Daily Scrum, 
empathic 

Risk 

Progressive elaboration, risk- 
adjusted backloq 

Procurement 

Agile contracting methods 

Stakeholder 

Scrum Master, Product 

Owner, servant leadership 


Table 1 - Agile topics by PMBOK area 


It is interesting to make a three-way comparison 
between traditional Gantt charts to burndown 
charts to Kanban boards. Gantt charts provide 
for the most complexity with relationship among 
tasks that are all estimated. Burndown charts 
show task estimates, but no task relationships. 
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Kanban displays task status without relationships 
nor estimates. 

Cost 

Project Cost Management deals with the financial 
resources of projects. All students should 
understand the interrelationships between 
project scope, cost, and time. However, it is 
interesting that scope is the area that varies in 
agile projects, while cost and time are relatively 
fixed. Cost concepts emphasized in the PMI-ACP 
are the traditional financial evaluation methods of 
net present value (NPV) and return on investment 
(ROI). 

Quality 

Project Quality Management for agile projects in 
particular is concerned with the need-satisfying 
aspect of a project's unique purpose. Essential to 
project quality management is satisfying key 
stakeholder needs or expectations. User 
acceptance testing involves independent testing 
by users of working software at the end of each 
iteration. Agile projects need an agreed upon 
definition of done that includes a quality criterion. 
Escaped defects is a measure of agile software 
quality. The goal is zero escaped defects, 
meaning that all defects are detected and 
corrected by testing during development. 

Human Resource 

Project Human Resource Management is the area 
that seeks balance between the needs of people 
and the needs of the project. The Scrum Team is 
the primary human resource needed to complete 
an agile project. A project manager, or Scrum 
Master, needs to develop soft skills, such as 
emotional intelligence to effectively work with 
other people in the project. Emotional 
intelligence the ability to identify, use, 
understand, and manage feelings in positive ways 
to relieve stress, communicate effectively, 
empathize with others, overcome challenges, and 
defuse conflict (managedagile.com). 

Communication 

Project Communication Management covers all 
activities related to project information. A key 
idea here is to keep project stakeholders 
informed. Until recently, project stakeholder 
management was covered in this area but now 
has come the tenth and newest PMBOK area. 
Now, the emphasis is not only to keep them 
informed but engaged. Key among stakeholders 
are users. In an agile project, they are engaged 
by their co-location with the project team and 
through empathic or active listening. Another 
critical stakeholder-related communication in 
agile projects occurs among team members in 
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daily standup meetings. In Scrum, the Daily 
Scrum communicates three pieces of 
information—what was recently completed, what 
is to be done today, and what obstacles are being 
faced. 

Risk 

Project Risk Management deals with addressing 
areas of positive or negative uncertainty that can 
affect a project. Schwalbe identifies progressive 
elaboration as one of the attributes of a project. 
Progressive elaboration is that property that 
concerns how uncertainty is reduced as a project 
becomes clearer in more detail as it proceeds 
forward. Furthermore, effective risk management 
can help reduce uncertainty faster and more 
effectively. Risk-adjusted backlog is an agile 
approach to prioritizing user stories 
(Senevirathne, 2014) that is identified as a risk 
management topic in the Tools and Techniques 
section of the PMI-ACP exam. It adopts the 
principle of addressing riskiest items first. 

Procurement 

Project Procurement Management concerns the 
use of project resources outside the organization. 
Usually, contracts are used to enforce 
agreements. Agile projects are highly non- 
traditional. When establishing contracts for agile 
development, non-traditional contracts are 
needed or else the project will be in danger of 
failing to reap the benefits of agile approaches 
(Arbogast, Larman, & Vodde, 2012). For 
example, agile contracts should codify that scope 
changes during a project be handled in a way that 
corresponds to agile's value of responding to 
change. Agile contracting methods is identified in 
the PMI-ACP as a knowledge and skill, along with 
vendor management, as the only two 
procurement topics. 

Stakeholder 

Project Stakeholder Management is the newest 
PMBOK area, being separated from 
Communications. See Communication above. In 
agile Scrum projects, there is no project manager 
in the traditional sense (Hunton 2012). Instead 
there is a Scrum Master who facilitates the Daily 
Scrum, and a Product Owner, who ensures 
business value by overseeing the scope 
prioritization process. Servant leadership is listed 
as a concept in the soft skills negotiation section 
of the PMI-ACP exam. Stakeholders are the 
beneficiaries when project managers serve by 
putting others first. 

4. STUDENT LEARNING OUTCOMES 
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During this year's first delivery of the project 
management course that included agile concepts, 
and afterwards, we developed and refined a set 
of course objects for what we are arguing is a best 
set of agile project management concepts. 

1. Evaluate the suitability of agile methods for use in 
a given project and organization context 

2. Analyze project proposals using multiple 

techniques 

3. Compare and contrast traditional versus agile 
project management 

4. Demonstrate an awareness of agile project 
management basic terminology and concepts 
across multiple PMBOK areas. 

5. Apply agile PM principles and techniques for 
managing in multiple PMBOK areas 

6. Discuss the soft skills and abilities of project 
managers 

7. Complete team-based work applying the principles 
and tools of project management 

5. ASSESSING STUDENT PERFORMANCE 

As with other topics in the course, student 
performance on agile topics varied. Towards the 
end of the course, students were given a 
Readiness Assurance Test (RAT) on agile project 
management. A RAT is a type of quiz given in the 
Team-Based Learning (TBL) pedagogy 
(Michaelsen et al., 2004). First, individuals are 
quizzed (iRAT) typically with ten multiple choice 
questions on a topic area worth four points each. 
The same quiz is then taken by the permanent 
teams (tRAT), using a scratch-off-the-answer 
card called an IF-AT (Immediate Feedback 
Assessment Technique). 


RAT #4 - Agile (max score=40) 


Team 

Team 

Team 

Team 

Team 


1 

2 

3 

4 

5 

iRATs 

34 

36 

32 

29 

36 


32 

33 

31 

28 

36 


30 

26 

30 

24 

34 


24 

25 

30 

20 

32 


19 

24 

28 


28 




22 



tRAT 

38 

36 

36 

36 

38 


Table 2 - Agile RAT results 


On the iRAT, 17 of 25 students received a passing 
score of 70% (28 of 40 points). The mean was 
73%. The tRAT scores were all at 96% or above. 
See Table 2. These RAT scores were consistent 
with how students typically perform on iRATs and 
tRATs. The grand means for iRATs (n=4) in that 
semester was 72% and the grand mean for tRATs 
was 94%. These results indicate that students 
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mastered the agile PM material similarly to other 
course content. 

However, performance on the midterm and final 
exams was lower than historical averages in the 
project management course. The midterm 
average was 68% compared to 78% over the 
previous three semesters. The final exam 
average was 71% compared to 80% historically. 
The students performed similarly on both 
traditional and agile PM content, and with the 
agile PM content making up less than 20% of 
exam content. We are uncertain as to why exam 
performance trended lower during a semester 
when RAT performance remained stable. Could 
the additional agile content have made the course 
too content heavy? We believe not. As part of 
the review for the final exam, the students were 
given a surprise, review quiz—a comprehensive 
RAT consisting of all questions from prior RATs. 
The overall performance, a mean score of 76%, 
was only slightly above the 72% grand mean of 
the original iRATs, and far below the 94% tRAT 
performance. Because students had collaborated 
and were exposed to correct answers, their 
performance on the re-take would have been 
better, we thought. One Team-Based Learning 
instructor (Goodson, 2004) reported that her 
surprise RAT retakes usually average 80%+. Due 
to the somewhat low recall, and below average 
performance on exams, more review and 
reflection is needed during the semester. 

6. CONCLUSIONS 

In addressing the research question on 
identifying the best set of agile concepts and 
practices appropriate for an IS project 
management course, we surmised that these 
concepts and practices could be taught alongside 
traditional project management topics, that the 
these topics could fit broadly across project 
management knowledge areas, and that these 
topics should emphasize project over product 
knowledge. 

Agile Alongside 

While adding agile content throughout the course, 
we continued to teach traditional approaches, 
such as the critical path method, while adding 
agile topics like the burndown chart on the same 
knowledge area. It is important to point out, 
however, that we do cover the entire Schwalbe 
text, and in each knowledge area, we did not try 
to juxtapose both a traditional and an agile 
concept. We simply added agile topics. The issue 
with adding agile topics is that the course could 
become topic-heavy. Students in our class were 
able to master agile concepts similarly to other 
topics, given our results in the RAT. But, student 
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performance on the midterm and final exams was 
lower than historical averages. 

Agile Across 

We were easily able to find important agile topics 
in each knowledge area. All topics came from 
either the Scwhalbe text, the PMI-ACP exam 
content guide, or a literature source. The 
toughest area to find something was 
procurement, but we did find an important 
concept (agile contracts) that received mention in 
the PMI-ACP exam content guide and for which 
there was literature. 

Project Not Product 

The topics we chose were project management 
topics. We did not have to resort to teaching non¬ 
project management topics like programming. 
However, in the case of the planning poker 
estimation exercise, we realized that students in 
this case were not expert enough to be able to 
make confident estimates for (programming) 
tasks, given the lack of information in the case. 
In the future, we might stick to the burndown 
chart and Kanban exercises, or tweak the 
planning poker exercise to avoid this problem. 

7. RECOMMENDATIONS 

We make the following recommendations to 
faculty members considering adding agile PM 
coverage in their project management course. 
First, choose at least one learning outcome 
related to agile PM for focusing your effort. We 
suggest that the lowest level outcome would be 
at the awareness level, and that this one would 
be outcome 4—demonstrate an awareness of 
agile project management basic terminology and 
concepts across multiple PMBOK areas. Second, 
we recommend that you emphasize agile project 
management concepts across multiple PMBOK 
areas, and without dropping traditional PM 
content. Third, we recommend that you assess 
agile PM so that you can isolate student mastery 
independent of the rest of the content, so that 
your intervention can be evaluated. Fourth, we 
recommend review of material prior to 
comprehensive testing. Fifth, we recommend 
additional literature review for discovery of 
concepts, methods, and approaches to teaching 
agile PM that may be informative but fell outside 
of the reach of this study. 

8. FUTURE WORK 

Our future work begins with getting the learning 
outcomes right. We believe we are close, now. 
What's important is that students have some 
awareness and appreciation of agile so that they 
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can converse intelligently with other 
professionals, i.e. in a job interview, and are 
prepared to hit the ground running when thrust 
into an agile environment. So, a set of low-level 
outcomes that reflect fundamentals mixed in with 
some application is warranted. The compare and 
contrast outcome may be the most important 
one, not so much to differentiate approaches, but 
to be able to evaluate effectiveness. It is 
important to educate students so that they may 
innovate in order to improve. 

Once outcomes are revised, then the task is to 
adjust content accordingly. We will remove any 
content not necessary to make sure the course is 
not becoming content-heavy. We will then adjust 
assessments accordingly, so that each outcome is 
effectively assessed. An effective set of 
assessments can then be used to "certify" that 
students are agile-ready. We will also look at 
midterm and final exam results, making sure 
students are performing at expected levels. 
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